The advent of cloud-based computing architectures has opened new possibilities for the rapid and scalable deployment of virtual Web stores, media outlets, social networking sites, and many other on-line sites or services. In general, a cloud-based architecture deploys a set of hosted resources such as processors, operating systems, software and other components that can be combined together to form virtual machines. A user or customer can request the instantiation of a virtual machine or set of machines from those resources from a central server or cloud management system to perform intended tasks, services, or applications. For example, a user may wish to set up and instantiate a virtual server from the cloud to create a storefront to market products or services on a temporary basis, for instance, to sell tickets to or merchandise for an upcoming sports or musical performance. The user can subscribe to the set of resources needed to build and run the set of instantiated virtual machines on a comparatively short-term basis, such as hours or days, for their intended application.
Typically, when a user utilizes a cloud, the user must track the software applications executed in the cloud and/or processes instantiated in the cloud. For example, the user must track the cloud processes to ensure that the correct cloud processes have been instantiated, that the cloud processes are functioning properly and/or efficiently, that the cloud is providing sufficient resources to the cloud processes, and so forth. Due in part to the user's requirements and overall usage of the cloud, the user may have many applications and/or processes instantiated in a cloud at any given instant, and the user's deployment of virtual machines, software, and other resources can change dynamically over time. In cases, the user may also utilize multiple independent host clouds to support the user's cloud deployment. That user may further instantiate and use multiple applications or other software or services inside or across multiple of those cloud boundaries, and those resources may be used or consumed by multiple or differing end-user groups in those different cloud networks.
In terms of the administrative capture of a user's resource consumption that may be spread across several independent host clouds, existing platforms today provide no mechanism by which a resource provider and/or other operator or administrator can track the resource consumption by the user across all currently utilized host clouds, in an organized or centralized fashion. That is, the user may have instantiated a certain number of instances or copies of an operating system or application in one host cloud, while at the same time running or executing another number of instances of the same operating system or application in another, independent host cloud or clouds. In instances, the set of host clouds may operate independently and with no operating agreement between them. Usage data for the user may therefore not be shared or be visible between those host clouds. In addition, the set of host clouds can also change over time during the course of a week, month, and/or other period, making coordination of subscription details including usage history difficult or impossible.
In cases where the user may subscribe to operating system, application, and/or other software or hardware resources based on subscription levels or limits, it may accordingly be difficult or impossible to keep a running tally of the user's resource consumption on an aggregate basis, across all operative host clouds. If the user, for instance, has a subscription limit of 300 instances of an executing application with a per-cloud limit of 100 instances, and reaches 100 instances in one host cloud at the same time that 90 instances of that application is operating in a second host cloud and 120 are operating in a third cloud, the application provider, individual host clouds, and/or other entities may not be able to timely or accurately determine that the user has reached their instance limit in one cloud, and exceeded their instance threshold in a second cloud. This can occur, for example, because individual host clouds may not have visibility on the resource consumption and/or subscription limits or parameters that may apply in other clouds. Moreover, those entities and their associated billing infrastructure may not be equipped to identify not just over-consumption of resources within certain subscription or usage periods, but also under-consumption of those resources. The individual host clouds and other entities may therefore not be able to accurately apply the user's subscription limits and/or other parameters, such as supplemental billing for over-limit resource consumption, on an aggregate basis. Among other things, this may prevent any individual host cloud, or application provider or other resource provider, from identifying the potential under-consumption of one or more subscribed resources in diverse host clouds that could, in theory, be captured and aggregated to permit the user to receive a credit, offset, and/or other adjustment to their overall subscription costs, on an aggregate basis.
It may be desirable to provide systems and methods for aggregating marginal subscription offsets in a set of multiple host clouds, in which a centralized entitlement engine or other logic can track, maintain, organize and combine relatively short-term consumption records, and potentially generate billing records that contain adjustments or reconciliations of varying under-and-over consumption events across diverse, and possibly unrelated host clouds.